Use pcmk_unpack_scheduler_input instead.

… fails.

This function can return a couple error codes, most notably when called
on input with a feature set that is newer than the latest supported.  In
that case, the caller should return its own error instead f trying to
continue on with an unpopulated scheduler object.  This prevents a
cascade of error messages.

Also, there's no need to do any error reporting.  pcmk__config_err will
have already called crm_err in this case.

The error message is hidden and only gets displayed if -V is given on
the command line.  Adding config error/warning handlers will cause the
error to be displayed regardless.

This could have been implemented in a couple ways, and there's tradeoffs
here.  I've chosen to duplicate what's happening in crm_verify, but
instead of checking for verbosity (which is a global variable in that
file), I'm checking out->is_quiet.

This means that if you do `crm_simulate -Q`, you won't see the error
message but you will get an error return code.  This also means that
`crm_simulate -Q -VVVV...`, you still won't see the error message.  This
may be a bug, but I'm not sure who would do that and I also think these
sorts of problems are pervasive in our command line tools.

Fix T521

This is just like the previous patch for crm_simulate, complete with all
the same problems regarding -Q and -V.

This is just like the previous patch to crm_simulate.  However, one
additional problem here is that it relies on using the deprecated -Q
command line option.  On the other hand, I think this is okay because we
have a lot of work to do straightening out these sorts of options for
all our command line tools.  This is just one more thing we'll have to
deal with at that time.

This takes care of all callers of pcmk__output_cluster_status and
pcmk__status.  pcmk_status would also be affected, but at the moment
there are no users of that function and anyway the config error handlers
aren't public API.

The point of this is to allow it to return the value from unpack_cib,
which is returning the value from cluster_status.  This allows us to
check whether that function hit the too-new feature set CIB condition.

…tions.

This takes care of most callers - the ones in the daemons are unlikely
to be a problem.  This allows catching the too-new schema condition in
various other tools and displaying an error message to the user.

Note that a couple other callers don't need to check the return value.
I've added comments explaining why.

* Remove the leading function name from various messages.  This was most
  commonly "unpack_resources".

* In the XML output format, move various messages from text that gets
  printed out to the XML output itself.  This does end up with somewhat
  weird output with status="0" message="OK" followed by some error
  messages.

* Add a couple warnings to crm_resource output.